C,Limit scale of initial project,Version control as documentation tool,Existing expertise leading to quick results,Proof of concept,Chaotic context,Oversight of current and near-future work,Online chat service as documentation tool,Documentation as a side product,Not Agile development,Manual testing,Co-location reduces need for organized communication,Limit overhead,Digital Kanban,Flat management structure,Iterative development,47,42,15,Prototype designed to answer fundamental „is the intended solution technologically implementable?“ question,Version control,Version control change history and commit message reasoning as documentation,Trello less useful during chaotic periods – projects/tasks changed too rapidly for a static view to be helpful,Kanban task management,Not Agile development because of lack of sprints,Direct communication rather than online discussion while co-located in part due to each team member being able to have near total group information (who is doing what and why) in a <=5 person team,Ability to resume old discussions in online chat service,Documentation of current and planned work,Task status updates at beginning of each workday,No need for detailed definitions/design of proof of concept,At least one part-time founder,Proof of concept as small/simple as possible,No co-working experience within team can include lack of trust in the form of more work quality checks – more overhead but can increase code quality,Online chat service increases in usefulness when not co-located over Google Docs likely due to real-time communication ,No sprints,Iterative prototype development increasing knowledge,Low usage of task assessment and planning procedures,Real world prototype hardware components affect testing results,No unit testing of hardware (including software) prototype,Document lookup time an important factor for documentation management,Constant communication supported by team co-location,Document comments supported pin-point discussion on issues,One usability test takes a long time for hardware sensors – gathering false positives or negatives over time,Structured documentation procedures too large of an overhead for a team of <=5 persons.,Task time logging of no value for a startup,Constant communication reduced need for task status meetings,Little need for documentation due to small team size of less than 5,Ability to organize online communication in online chat service,Software for hardware prototype too simple for automated unit testing,Priority on supporting tools the team knows to minimize new thing to learn,Not formal designs or architecture for hardware (including software) prototype,Non-descriptive commit messages are an issue when relying on them for documentation of reasoning/explanation of changes,Uncertainty a bigger issue than development procedures – What to do comes before how to do,Important that management tool does not involve too much overhead for team,Small startup too chaotic to long term work planning,Solution and supporting software setup instructions documented in version control,Ability to keep separate task discussion logs in online chat service,Low communication overhead of spreading information to everyone in small teams,Documentation through version control readme documents,Group decision making,Documentation of rough designs,Trello most useful for projects/tasks with a defined beginning and end – not all startup projects/tasks fit that criteria,Responsibility of solution modules documented in version control,Slack for team communication – enables communication history lookup,Prior experience working together of great benefit to startup – eliminates group formation costs,This prototype‘s requirements discovered by earlier prototype
